allow custom initialization of the HandlerType of the LambdaRuntime #310

tomerd · 2023-10-10T21:28:56Z

Motivation: Provide the flexibility for custom initialization of the HandlerType as this will often be required by higher level frameworks.

Modifications:

Modify the LambdaRuntime type to accept a closure to provide the handler rather than requiring that it is provided by a static method on the Handler type
Update downstream code to use HandlerProvider
Update upstream code to support passing Hanlder Type of Handler Provider
Add and update tests

Originally suggested and coded by @tachyonics in #308

tomerd · 2023-11-01T19:27:00Z

@tachyonics wdyt?

tachyonics · 2023-11-04T05:57:08Z

@tachyonics wdyt?

This will work for our use case although not quite as convenient as what I had. My only concern is that handlerProvider returns a ByteBufferLambdaHandler which has a makeHandler function requirement that will not actually get used. In our code we can just not implement that method but conceptually it seems a bit odd at the runtime level.

tomerd · 2023-12-01T19:24:09Z

@tachyonics wdyt about 792d1c1? I dont love the name CoreByteBufferLambdaHandler but hopefully this address the need better?

tachyonics

@tomerd I am not really a fan of the name either but otherwise the changes look good and are more consistent.

tomerd · 2023-12-01T20:21:23Z

thanks @tachyonics, so now to the hard part - choosing a name.

cc @fabianfett @sebsto @yim-lee @ktoso

any good ideas?

tachyonics · 2023-12-07T04:20:04Z

so now to the hard part - choosing a name

@tomerd NonInitializingByteBufferLambdaHandler?

tomerd · 2023-12-07T18:30:20Z

@tachyonics updated to NonInitializingByteBufferLambdaHandler. wdyt?

Sources/AWSLambdaRuntimeCore/LambdaRuntime.swift

Sources/AWSLambdaRuntimeCore/Lambda.swift

Sources/AWSLambdaRuntimeCore/LambdaRuntime.swift

tachyonics · 2023-12-07T21:35:54Z

Just some small comments about comments. Otherwise lgtm.

tomerd · 2023-12-08T21:11:54Z

@tachyonics new name idea: LambdaRuntimeHandler. wdyt?

@tachyonics

Motivation: Provide the flexibility for custom initialisation of the HandlerType as this will often be required by higher level frameworks. Modifications: * Modify the LambdaRuntime type to accept a closure to provide the handler rather than requiring that it is provided by a static method on the Handler type * Update downstream code to use HandlerProvider * Update upstream code to support passing Hanlder Type of Handler Provider * Add and update tests Originally suggested and coded by @tachyonics in awslabs#308

Sources/AWSLambdaRuntimeCore/Lambda.swift

tachyonics · 2023-12-08T22:03:38Z

I'm good with this!

tomerd · 2023-12-09T03:10:59Z

@fabianfett any concerns?

fabianfett · 2023-12-16T21:00:43Z

Tbh. I think this doesn't solve the actual issue. The lifetime handling in Lambda was designed and implemented before ServiceLifecycle came about. For this reason, using long running clients in Lambda currently feels absolutely weird.

For this reason, I think, we should reconsider what the Lambda API should look like taking into account that it should play nicely with ServiceLifecycle.

General ideas:

LambdaRuntime should implement Service
If a Lambda runs locally it should set up a ServiceGroup to handle signal handling
If a user needs long running Services within their Lambda they should be able to use ServiceGroups to manage their lifetimes.

tomerd mentioned this pull request Oct 10, 2023

Allow custom initialisation of the HandlerType of the LambdaRuntime. #308

Closed

tomerd force-pushed the feature/handler-provider branch 2 times, most recently from e7ed5fd to 6aafe79 Compare October 10, 2023 21:36

tachyonics approved these changes Dec 1, 2023

View reviewed changes

tomerd force-pushed the feature/handler-provider branch from c0cf6d3 to f642509 Compare December 7, 2023 18:29